Role-based access control

In computer systems security, role-based access control (RBAC)[1][2] is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees,[3] and can be implemented via mandatory access control (MAC) or discretionary access control (DAC). RBAC is sometimes referred to as role-based security.

Contents

RBAC model

Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the computer permissions to perform particular computer-system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user's account; this simplifies common operations, such as adding a user, or changing a user's department.

Three primary rules are defined for RBAC:

  1. Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
  2. Role authorization: A subject's active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
  3. Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject's active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.

Additional constraints may be applied as well, and roles can be combined in a hierarchy where higher-level roles subsume permissions owned by sub-roles.

With the concepts of role hierarchy and constraints, one can control RBAC to create or simulate lattice-based access control (LBAC). Thus RBAC can be considered to be a superset of LBAC.

When defining an RBAC model, the following conventions are useful:

  • A subject can have multiple roles.
  • A role can have multiple subjects.
  • A role can have many permissions.
  • A permission can be assigned to many roles.
  • An operation can be assigned many permissions.
  • A permission can be assigned to many operations.

A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate separation of duties. For example, the same person should not be allowed to both create a login account and to authorize the account creation.

Thus, using set theory notation:

A subject may have multiple simultaneous sessions with different permissions.

Relation to other models

RBAC is a policy neutral and flexible access control technology sufficiently powerful to simulate DAC[4] and MAC.[5] Conversely, MAC can simulate RBAC if the role graph is restricted to a tree rather than a partially ordered set.[6] Prior to the development of RBAC, MAC and DAC were considered to be the only known models for access control: if a model was not MAC, it was considered to be a DAC model, and vice versa. Research in the late 1990s demonstrated that RBAC falls in neither category.[7] Unlike context-based access control (CBAC), RBAC does not look at the message context (such as a connection's source).

RBAC differs from access control lists (ACLs), used in traditional discretionary access-control systems, in that it assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. For example, an access control list could be used to grant or deny write access to a particular system file, but it would not dictate how that file could be changed. In an RBAC-based system, an operation might be to 'create a credit account' transaction in a financial application or to 'populate a blood sugar level test' record in a medical application. The assignment of permission to perform a particular operation is meaningful, because the operations are granular with meaning within the application. RBAC has been shown to be particularly well suited to separation of duties (SoD) requirements, which ensure that two or more people must be involved in authorizing critical operations. Necessary and sufficient conditions for safety of SoD in RBAC have been analyzed. An underlying principle of SoD is that no individual should be able to effect a breach of security through dual privilege. By extension, no person may hold a role that exercises audit, control or review authority over another, concurrently held role.[8][9]

Use and availability

The use of RBAC to manage user privileges (computer permissions) within a single system or application is widely accepted as a best practice. Systems including Microsoft Active Directory, Microsoft SQL Server, SELinux, grsecurity, FreeBSD, Solaris, Oracle DBMS, PostgreSQL 8.1, SAP R/3, ISIS Papyrus, FusionForge and many others effectively implement some form of RBAC. A 2010 report prepared for NIST by the Research Triangle Institute analyzed the economic value of RBAC for enterprises, and estimated benefits per employee from reduced employee downtime, more efficient provisioning, and more efficient access control policy administration.[3]

In an organization with a heterogeneous IT infrastructure and requirements that span dozens or hundreds of systems and applications, using RBAC to manage sufficient roles and assign adequate role memberships becomes extremely complex without hierarchical creation of roles and privilege assignments. Alternate strategies for large scale assignment of privileges to users are discussed in this white paper: Beyond Roles: A Practical Approach to Enterprise User Provisioning. Newer systems extend the older NIST RBAC model[10] to address the limitations of RBAC for enterprise-wide deployments. Several academic papers exist. The NIST model was adopted as a standard by INCITS as ANSI/INCITS 359-2004. A discussion of some of the design choices for the NIST model has also been published.[11]

See also

References

  1. ^ Ferraiolo, D.F. and Kuhn, D.R. (October 1992). "Role-Based Access Control" (PDF). 15th National Computer Security Conference. pp. 554–563. http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf. 
  2. ^ Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (August 1996). "Role-Based Access Control Models" (PDF). IEEE Computer (IEEE Press) 29 (2): 38–47. http://csrc.nist.gov/rbac/sandhu96.pdf. 
  3. ^ a b A.C. O'Connor and R.J. Loomis (December 2010) (PDF). Economic Analysis of Role-Based Access Control. Research Triangle Institute. http://csrc.nist.gov/groups/SNS/rbac/documents/20101219_RBAC2_Final_Report.pdf. 
  4. ^ Ravi Sandhu, Qamar Munawer (October 1998). "How to do discretionary access control using roles". 3rd ACM Workshop on Role-Based Access Control. pp. 47–54. 
  5. ^ Sylvia Osborn, Ravi Sandhu, and Qamar Munawer (2000). "Configuring role-based access control to enforce mandatory and discretionary access control policies". ACM Transactions on Information and System Security (TISSEC). pp. 85–106. 
  6. ^ D.R. Kuhn (1998). "Role Based Access Control on MLS Systems Without Kernel Changes" (PDF). Third ACM Workshop on Role Based Access Control. pp. 25–32. http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/kuhn-98.pdf. 
  7. ^ See National Institute of Standards and Technology FAQ on RBAC models and standards, and the research of David Ferraiolo and Richard Kuhn.
  8. ^ D.R. Kuhn (1997). "Mutual Exclusion of Roles as a Means of Implementing Separation of Duty in Role-Based Access Control Systems" (PDF). 2nd ACM Workshop Role-Based Access Control. pp. 23–30. http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/kuhn-97.pdf. 
  9. ^ Ninghui Li, Ziad Bizri, and Mahesh V. Tripunitara . Tripunitara (2004). "On mutually exclusive roles and separation-of-duty," (PDF). 11th ACM conference on Computer and Communications Security. pp. 42–51. http://portal.acm.org/citation.cfm?id=1030091. 
  10. ^ Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). "The NIST Model for Role-Based Access Control: Toward a Unified Standard" (PDF). 5th ACM Workshop Role-Based Access Control. pp. 47–63. http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf. 
  11. ^ Ferraiolo, D.F., Kuhn, D.R., and Sandhu, R. (Nov/Dec 2007). "RBAC Standard Rationale: comments on a Critique of the ANSI Standard on Role-Based Access Control" (PDF). IEEE Security & Privacy (IEEE Press) 5 (6): 51–53. doi:10.1109/MSP.2007.173. http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-sandhu-07.pdf. 

External links